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(57) Abstract: A security architecture has been dew>lmv»H in « • i - 

maintain continuity of a persists session ^S^^^^Z " ^ ^ « 10 

across credential .eve. changes. Session credential are seSSd e g as "SZZSST T " S ° me embotto ^. 
may be inspected by a wide variety of entities or aDolicationTio "^'nX X 8eCured SCSS,0n ,0ken - such *ey 

alu^ except byatrustedaumendcLonser^re 1«2SS^n^Sh aUtheMlCated «"«" level - >« ™V not be prepared or 
infonnation resources. Authentication schem s"e * ~ "^S^T^T"^ ^ -I 1 *— 
are associated with trust levels, and in some embodiment wi,h!n paSSWC ", ds - Cemf,Cates ' *>*°™tnc techniques, smart cards, etc.) 
service ( , 20) obtains login e^J^^XST wtZST? "^T* — in ^figuration, a login 
resource or information resources^ g .9. 9 " JQSHofcJIlT.T ? i ** ^ re< » uire «) of an information 
given credential type. Once login aJtSi (e « J£ S ^ env — -t parameters that affect the sufficiency of a 
level, session credential (e.g. 420) are issued a c l ™ , " ""^ ^ haVe ^ authenticate ° «» « Pven tmst 

Advantageously, by using dTe session ^aiTacces StZ S 7TT f *" ^ " * Ufficien < 
In some configurations, session credentials evidencing Sclm W. , £ ^ '° gin CredeMiaU 30(1 au '"entication. 
upgrade of login credential. 8 ,nsufr,c,en ' «™« level may be remedied by a session continuity preserving 
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ACCESS MANAGEMENT SYSTEM AND METHOD 
EMPLOYING SECURE CREDENTIALS 



Technical FipIH 



The invention re.ates to infonnation security, and m0 re particular.y, to systems and method for 
improvmg the security of mformation transactions over networks. 

Background Art 

The interne, has become an unponan, medtum for mfonnation serv.ces and e.ectronic commerce As 
the tnterne, ha. been commercialized, organ.zations m.t.al.y established their presence in cyberspace by 
makmg .nformat.on (typically static, non-sens.tive promot.onal informat.on) ava„ab,e on resources we,, 
removed from the operat.ona, infrastructure of the organ.at.on. Secunry .ssues were often addressed by 
■so atmg pubhely access.ble resources (e.g., web servers) from more sensttive assets using firewal, techn.oues 
As long as the publicly access.b.e .nformat.on and resources were relatively non-sens.nve and user 
tnteracttons with such information and resources was no, m.ssion cntica,, re,at,ve,y smple firewall technioues 
were adequate. Though tnformat.on and resources outs.de the ftew.ll were at risk, the risk could generally be 
Utntted to non-proprietary .formation that was easi.y rep.aceab.e if compromised. Propnetary informahon 
and systems critical to day-to-day operates were she.tered behmd the firewall and infonnation flows across 
the firewall were fi.tered to exclude a„ but the comparative.y non-threatemng serv.ces such as electronic mai,. 

However, as the mteme, has become more pervas.ve. and as the soph.sricat.on of too.s and technioues 
has utcreased, severa, aspec.s of the secunry environment have changed dramatically. First, busmesses have 
recogntzed the power of infonnation transactions that more t.ght.y couple to operat.ona, data systems, such as 
order processing, inventory, payment systems, etc. Such transacts mc.ude electronic commerce with dtrec, 
purchasers or consumers (e.g.. browsmg, se.ectmg and purchasmg of books by members of the pub.ic from an 
on-.me bookseller) as we,, as supply chatn and/or business partner interacts (e.g.. automated just-in-time 
tnventory management, customer-specific pricing, availability and order status mformat.on etc ) 
Commercial relevant transactions increasing require .formation flows to and from secure operational 
systems. Second, even informauon-only services are mcreasing.y m.ssion-critical to their providers 
Corporate image can be adverse.y affected by unava„abil,ty of, or degradation access to, otherwise non- 
sens.t.ve infonnation such as customer, support mformation, product upgrades, or marketmg and product 
mfomuuon. Because many bustnesses re!y heavi.y on such facilities, both unauthonzed modification and 
denial of service represent an increasing threat. 

individual infonnation serv.ee or transacts system typically exhibit diffenng security requuements 
Wh.le „ .s posstble to field tnd.v.duahzed secur.ty solutions for each information serv.ee or transact™ 
system, mdividualized solutions make ,t difficult to matntain a uniform security policy across a set of 
apphcauons or resources. Furthermore, md.v.dua.tzed so.u.ions tend to foster .compatible security islands 
w.th.n what would ideally be presented to consumers or bus.ness partners as a single, tntegrated enterpnse 
For example, a user that has already been authent.cated for access to an order processing system may 
unnecessary be re-authenticated when accessing an order status system. Worse s,i„, a se, of individualized 
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solutions „ ^ ica „ y only „ $ood as , he wMkcs , so|ui . on a wc>k so|uiron maj _ ^ ^ ^ 

compromised through a low security entry point. 

Another p,„ b ,em with ,„d„,dua„ 2 ed S o, u , ions is . verilable ,„ ,„„ ^ ^ 

«-* --—, . use,. As more and more huanne* is conducted ushrg compoter systems, users are 
confronted w„h muluple tdentifters and passwords for various system, resources or levels of access 
Ata _ a „ raced with the huge prohiem of , s su„g. uachmg and revoklne 4e idenlffim 
— *eu users. As the W commumty grow, to include vendors, customers, potentia, customers 
consn tants and others in addttton „ erop.oy^, . huge , d explosion „ ft „ s 

mdtvtdn., users .,e confronted with „, 8 e numbers of tdennfters and passwords, adherence , ' 

case complex,,,, rohusmess to dic,io„„y or e.si,,-a s eer,a„ab,e inrorroation anaclc. fre()ue „ cy „ r updjle . 

Z h , ' d " " SerS IC, "" e ~ — '~ -r Have 50 or le^Io 
help but „r„e down or create e, sy .,„. remeraber , ,„„ „ sy ., 0 . compromj „ 

DISCLOSi IRF nr I NVENTION 

Sess „ A r d 7' y ' ' """" y m M ' » P'»vided 

SO on credent,,, « used , 0 ^ „ f , ^ ^ _ _ 

ore secured, e.g., ,s a crypmgraph.c.hy secured session tohen. such tha, .hey may be inspected hy a wide 
vartery of entttics „, appUe.t.ons to verify an au.hem.ced „ ieve,, ye, may no, he paired o a ,^ 
ncep, hy a roasted ,oune„,ic„io„ service. Some emblems of fc prescnl J'^e, 
„,„ tafc— d- resources. Authentication scheroes (e.g., those h.sed o„ p, sswords 

" ~' PlramC ' m F " " - • ■ — — logo, credent 

-ources, he accessed and »,m env.romnen, p„, melers ,„,„ ^ , 

hype. Once ,„g„ eredentials have hcen obtained for . enhhy „d h.ve heen ~^JL . given ^ 
ufneten Advancageouaiy. hy u s hn s the session crcdenttais access is granted without , he need for *J 

" ^ rem=< " ed by a " ss »" P'«cc«di 6 upgrade ofiogm credential 

In on, erohodtmen, ,„ accorddnce with Ok present invention, a sess.on credenti,, includes a prtncipa, 
■de ttfer u„, q ue, y ,de.hf y i„g a prtac , p „ ,„ d ,„ ^ % ^ «^ 

archttecntrc ,f,.r prior authenttcatton of a ,„g„ cred c„,i„ correspondmg to the principal. The prinL 

tdemtfte, and audtoruaa.ion encoding are cryptogmphically secured aaad allow dtc secnri, y nrdhiLZ 
eve u SK . mciency - fc for ^ ^ fc _ _ ^ ^ ^ J-« . 

authentication of the loEincredentiale: tn « n wimout re- 

secunty archi.e n Va^a,,0n, SeSSi0 " Creden " al h SUpP ' ied CX,en,al ** 

security architecture as a session token. 
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In nnofte, ennbodb™,, ft accordance wift fte „,„„,, inv „, 1<)n . , „ ssion lokcn is 
o .„ ,„fo„„„ lon resourc , sessl0 „ , oken ^ a jdeniifc S 

c~r sec ,nd ai,ow ,he secun,y >rehi,ec,ure - » f - — — * 

access ,o ,he ,nfom»„o„ resource wiftou, ,e-au,hemica,i„„ of fte login credenli,), 

lo Hill auofter euftod™, ft accordance svift fte p „ sem mvemlo „ , me|hod of 
an, o ra ,,„„ v „ir,ca,.o„ ft a seeuriry .robdeerure c„„oo„ft g .cceas ,. one or m „„ , nfonn „ ion 
neftdes ob„„ft 8 , , ogm creden,.., and aufte„,,c a ,ft g a p „„ ci p a , , nereby „ d issu ,„ g , „^ 

p™,c,pn, and frs, auftu™ accorded based o„ fte .ufteubcn.ftn. For „,„„, f „ 
■he one or more uf fte ft^a.ftn res „u re .s, fte ureftod banner ,„o,udes se.eCve.y a„„wft g access based 
^ency of fte fus, _ encoded by fte e„ lc „ ly !ecured ^ _ " 

ft one or m o,u of fte — — resoorces. .bereft fte se.ecbve a„oa,ft g „ p „ fora « d wkhou , .^.J, 
login credential authenticating. aaamonai 

In «0I ye, .nofto, emboftuseu, ft aooordao.e wift fte preseo, ,„ve„,,o„, no , n f onra „ on aecass 
conuol facduv urobades ,„ appbe.bon p,ox y ,„d m ea„s response ,o fte appbc.ioo P roa y ,T,e a pLon 
proxy ,s for rec.,o„ g „ access „„„«, „ rg e,,„ E one of fte ft,o™ a ,ft„ re soo,cea. o,L,ft g a 

The means ,espo„ s ,.e ,o fte appbc.uou proxy is for e,a,u a ,u, g s ofr,c,e„e y of „ authoriza , id „ 
nryp^aphacaHy secured sess.on ,o k e„ for access ,o fte ,u, g e,ed ftfo™,™ resource. 

BRI EF DESCRIPTION Q F OR AWTtsj^g 

The present Mention may be better understood, and its numerous objects, features and advances 
made apparent to those skilled in the art b y referenctng the accompanymg drawings. 8 

FIG. . is a b«ock diagram i.lustrattng mformat.on flows between components in a security 
arch-tecture emp.oy.ng secure sess.on credent m accordance with an exempt embod.ment of *e present 

credent 7^ ' " ^ ^ * ' ***** ***** ~« «— 

credent la .s tn accordance with an exemplary embodiment of the present invent.on. 

secuntv ' " IUStrateS ' nteraC "° nS betWee " fUnC,,0^a, C ° mP ° nentS 3 Composition of a 
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FIG. 4 illustrates relations between login credentials, sess.on credentials and a cook.e encoding of a 
sess.on token ,n accordance with an exemplary embodiment of the present invention. 

T^e use of the same reference symbols in different drawings indicates s.mi.ar or .dentical .terns. 

MODE(S) FOR Carryin g out thf tnvention 

Some terminology used in this specification has mean.ng particular to the context of embod.ments 
descnbed here.. Therefore, to a,d persons of ord.nary ski., in the an un understand the full scope of the 
invention, some of that terminology is now defined. 

Glossary 



Access Management: Systems, methods and techn.ques for controlling use of ^formation resou, 
Typtcally, access management systems employ both authent.cation and authorization to control access to 



Authentication: A process used to verify the identity of an entity. As typica.ly unp.emen.ed an 
authenncation method is employed to venfy the identity of a user or object based on a credential supplied by 
the user or object. F y 

Authorization: A process for determining whether an ident.ty is permitted to perform some acnon 
such as accesstng a resource. Typ.cal.y, an identity will be authent.cated, though in some configurations ' 
certain identities need not be. 

Credential: Ev.dence of identity used to authentic an entity. Exemplary credent.a.s types .nc.ude 
passwords certificates or other encrypted indicia based on asymmetnc, symmetric, public, pr.vate, or secret 
key technolog.es. one-time passwords, biometric indicia such as by rehna. scan, vo.ce print, finger print etc 
and possess™ based ind.cia such as smart cards, Enigma cards, keys, etc. In some reasons, credential " 
may be associated with users, sessions, functional objects, etc. 

Digital Signature: A transformation of a message using an asymmetric cryptosystem such that a 
person havmg the initia. message and the signer's publ.c key can accurately determine whether the 
transformation was created usmg the pnvate key that corresponds to the s.gner's public key and whether the 
message has been altered since the transformation was made. 

Entity: A user or object, inc.ud.ng data objects and/or functional objects such as appl.cations 
components, modules, services, processes, threads, etc., as weli as instantiations thereof In some 
confi guratlons , oniy user cnthies (typjcal , y the human princ . pai mic ^ wj(h a so ^ are ^ ^ 

whose behalf a software agent purports to act) are cons.dered. In other configurations, entities include 
functional objects without an assoc.ated human pr.ncipa,. The idenuty of an entity may be authent.cated usmg 
a credential. * 
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Session: A period and collection of states spanning one or more interactions between an entity and an 
mformation environment. As used herein a session may span multiple interactions with multiple resources of 
the mformation environment and, in some configurations, may span multiple information access protocols 
(e.g., HTTP, FTP, telnet, etc.). A session has a beginning and an end. During its existence, a session has state. 
As used heretn, the term session connotes a greater persistence than as sometimes used to describe the penod 
of a "session layer" protocol interaction, which in the case of some protocols, such as HTTP, is generally very 
short-lived. 

Single Sign-on Se curity Architecture 

FIG. 1 provides an overview of major interactions between components for an exemplary security 
architecture in accordance with the present invention. As illustrated in FIG. 1, a client application eg a 
browser 170 operated by a user, mteracts with the security architecture via a gatekeeper and entry handler 
component 1 10 and a login component 1 20. Gatekeeper and entry handler component 1 10 provides an entry 
po.ni for externa, client applications requesting access to enterprise applications and/or resources including 
e.g., mformation resources 191, 192 193. for which access management is provided by the security 
arch.tecture. Using facilities prov.ded by a sess.on management component 160, an authorization component 
140, an au,hent.cat.on component 130, an .dentification component ISO, and log.n component 120 the 
gatekeeper/entry handler component 110 allows, redirects or refuses access requests in accordance with a 
security policy. 

Individual mformation resources typically have differing security requirements. In addit.on 
individual types of access to a single informat.on resource may have differing security requirements 
Nonetheless, a given level of secunty may be sufficient for more than one of the information services or access 
types. For example, information resource 191 may include a product informarion serv.ee for providing genera, 
information such as product descriptions or data sheets to the public, while information resource 192 includes 
an order processing system for an eCommerce site. Information resource 193 may include functions for 
supply chain interactions such as access to inventory informat.on or current selling price mformation. Bom 
the product information service and order intake functions of the eCommerce may operate with similar 
security requirements, e.g., allowing access by minimally authenticated, non-hostile entities. On the other 
hand, supply chain functions may require a higher level of security. Order status functions of the order 
processing system may require a mid-level of security. 

Login component 120, operating in conjunction with gatekeeper/entry handler component 110 and 
other components of the security architecture, provides a single sign-on interface for access to enterprise 
applications and/or resources. In an exemplary embodiment, security requirements are expressed in terms of 
trust levels and login component 120 obtains login credentials for an entity requesting access to one of the 
enierpr.se applications and/or resources. The log.n credentials obtained are selected from a set ofcredential 
types that, ,f authenticated, are sufficient to achieve the trust level requ.rement of an application or information 
resource to be accessed. Without limitation, typical login credential types and associated authentication 
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In certain embodiments in accordance with the present invention, a credential upgrade facility is 
prov.ded. In response to an access request from an entity for which login credentials have aheady been 
obtamed and authent.cated. but for which the obtamed and authenticated login credentials are insufficient for 
the tms, level associated with the requested access, authorization component 140 may indicate that the access 
request ,s to be redacted to login component 120 so that sufficient login credent.als may be obtamed and 
authenncated to the requ.red trust level. Of note, credent., upgrade facilities in accordance with certa.n 
embod.ments of the present invention allow upgrade without loss of session continuity. 

In addition to the obtained login credentials, some configurations in accordance with the present 
•nvention employ session credentials as a mechanism for evidencing pr.or authentication of obtamed login 
credentials and for binding individual transactions to a particular session. In some configurations sess.on 
credentials are a.so employed in a session token form advantageous for transactions external to the secunty 
architecture. In an exemplary realization, session tokens are encoded for supply to browsers as cookies 
FIG. 4 illustrates relationships between exemplary login credential, session credential and session token 
objects. 

As described above, login credentials (e.g., represented in a form such as exemplary login credentials 
structure 410) are obtained for a Cent entity. Typ.ca.ly, login credentials encoded in login credentials 
structure 410 are obtamed from a principa. via browser client and serve as evidence that the principal (e g a 
human user) is entitled to a particular identity. Accord.ng.y, login credentials structure 4,0 encodes a userld 
and a domamld within wh.ch the userld should un.que.y correspond to a principal. Specific login credentials 
eg., a password, a certificate, resu.ts of a b.ometric process, a response to an Enigma challenge or results of a 
smart card interrogation, etc. are encoded in login credentials structure 4 10, as a tagged value An 
authenticationScheme is specified and creation time may be encoded to limit replay attacks In the 
implementation of FIG. 4, login credentials structure 410 is encrypted using the public key of an 
authentication service (e.g., of authentication component 130). Because the key is public, any component, 
even untrusted components may encrypt login credentials for provision to authentication component 130 
while only authentication component can decrypt the encrypted login credentials using its private key In 
some configurations, secure transfer protocols, e.g., SSL, are employed to secure login credentials between a 
chent entity such as browser 170 and the security architecture while encryption with a public key of an 
authenncanon service is performed within the security architecture, e.g., at login component 120. In other 
configurations, encryption with a public key of an authentication service may be performed at the diem entity. 

If the encrypted login credent.als provided to an authentication serv.ee are determined to be authentic 
session credent.als are .ssued. In the .mplementat.on of FIG. 4. session credentials are embodied in a form 
such as exemplary sess.on credentials structure 420. Encrypted and clear text portions (421 and 422) of 
session credentials structure 420 allow contents of the session credent,! to be read by anyone and changed by 
no one (except the authent.cat.on service possessing a pnvate key). Contents of encrypted portion 421 
correspond to that clear text portion 422 bu, are encrypted using the private key of the authenricat.on service 
(e.g.. of authentication component ,30;. Of note, principal ids, authorizations and other contents encoded in 
the session credent.al may be read by components ofthe security architecture, and .„ some embodiments by 
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components external to the secunty architecture. Such components can verify the authentic.ty of .nformarion 
stored ,n clear text portion 422 using encrypted portion 421 and a public key corresponding to the private key 
of the authentication service. Of note, the tnformation contained in a session credential is generally not 
sensitive. What is sensitive is the state of the tnformation. Therefore, security architectures employing 
fac.ht.es described here.n ensure that information contained in the sess.on credential is provably constant once 
se, by an authent.cat.on service. By ustng the public key of the authenticate serv.ce, wh.ch will in general 
be freely avadable, together with the encrypted .nformat.on, any appl.cation can read the .nformation (e g in 
free text) and ascertain that the sess.on credent.a. was created by the authenticat.cn service and that the sess.on 
credent.a. has not been tampered with. Assuming that the authent.cat.on service's pr.vate key has no, been 
compromised, tampering with the session credential will resu „ in a decryption failure. 

in an alternative .mp.ementat.on (not shown), sess.on credent.als may be digitally signed and verified 
by a pubhc key corresponding to a private key. In such an alternative .mp.ementation, the dig.ta. signature 
also allows contents of the session credential to be read by anyone and changed by no one For some 
configurations, the implementation of FIG. 4 is preferred because encrypted portion 42, can be used as an 
externally suppl.ed session token. Such a session token representat.on is a compact representation of the 
sess.on credential particularly appropriate for encoding as a cookie placed a, a browser and returned with 
subsequent access requests. 

Referring aga.n to session credentials structure 420, a session id, a principal id, a mist level group 
ids a creation tune and an expiration tune are encoded .n both in encrypted portion 42, and clear tex, portion 
422. The session id ,s a un.que identifier for a persistent session maintained by the security architecture In 
.mplementations in wh.ch credential upgrade is provided or in which a sess.on credential expiration and 
refresh ,s provided, multip.e successively issued sess.on credential instances may encode the same session id 
and correspond to the same pers.stent sess.on. Principal .d encodes an tdentifier for a principal to which the 
security architecture has resolved login credentials. For example, a login credential including a usemame jdoe 
and a password corresponding to jdoe may be resolved by the secunty arch.tecture to a unique principal id 
associated with John. Q. Doe of the shipping and rece.vng department, having an employee badge number of 
12345, etc. 

In some embod.ments. a trust level encodes the authorization level to which a principal has been 
authenticated. In such embodiments, the encoded trust level serves as a basis for evaluating whether a 
prtncpal associated w.th the session credentials has been authenticated to a sufficient level for access to a 
requested resource. For examp.e, a trust level of 5 may be sufficient for access to information resources 
having a trust .eve. requirement of 5 or less. Trust levels offer an attrac.ve decoupling of authortzat.on levels 
and authentication methods as described e.sewhere heretn. However, m some embodiments, an authorization 
encoding may establish that a principal has been authenticated using a particu.ax authentication mechanism In 
ether case, an authorization (e.g., encoded as a trust level) in a cryptographical.y secured session credential 
allows the security architecture to authorize accesses based on prior authentication of a .ogin credential and 
without involvement of the authentication service. 
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Group ids can be used ,o gran, or limit authorizat.on scope based on group membership. Typicaily 
sess,on credentials serve as ev.dence of pnor authentication and authorization for mu ,tip!e accesses to 
mformauon resources controlled by the secunty archttecture. However, session credentials may be replaced 
on a log™ credential upgrade as described elsewhere herein. In addition, session credentials of .united 
tempora. validity may be refreshed by periodic replacement. In the configuration of session credent.a.s 
stn.cn.re 420. creat.on time and exp.ration tune al.ow the secunty arch.tecture to .mprove resistance to replay 
attacks. Sess,on credent.a.s typically have a relatively short exp.rat.on time (e.g.. ,5 minutes from creat.on or 
.ess) and underly.ng login credent.a.s w.„ be reauthenticated prior to expiration of the session credentia. 
Assum.ng that the underly.ng login credent.a.s, wh.ch are stored under the pub., key of authent.cat.on 
component ,30, rema.n va.id, authenticat.on component ,30 wi.l issue a rep.acement cryptograph.cal.y 
secured sess.on credent,, (e.g., as sess.on credent.a.s structure 420). Depending on then current trust ,eve. 
mapp.ngs and. in some configurations, depending on men current env.ronment parameters, the authonzat.on 
accorded by the secunty arch.tecture and encoded as a trust .eve, may differ from that encoded in the sess.on 
credentia. replaced. If a princ.pa. id or log.n credential has been revoked, reauthent.cat.on may fail and a user 
5 may be prompted to supply a sufficient log.n credential as descr.bed elsewhere herem. Sess.on id and 

pnncpal id wi„ typicaHy remain the same for successive session credent.a.s associated with a s.ng.e pers.stent 
session. 

As prevous.y described, one advantage of the approach emp.oyed in sess.on credent.a.s structure 420 
, that encrypted portion 42, may a.so be emp.oyed as a compact sess.on token represen.at.on 430 of sess.on 
credent,, for use as a cookie. In one embodiment in accordance with FIG. 4, encrypted port.on 42, is a string 
encoded representat.on of approximate^ 200 characters which may be p.aced at a browser (e.g., via transfer 5 
23 or 23 A of FIG. 1 ) using a set cookie directive. 

Exemplary Configuration 

Referring to FIG. ,, an entity (e.g., a browser 170 operated by a user) interacts with enterprise 
apphcations and/or resources (e.g.. 191. ,92. 193) and the secunty arch.tecture via a gatekeeper/entry hand.er 
component 110 and a ,ogin component ,20. In genera,, a wide variety of entities, inc.uding human users 
operanng browser and/or non-browser client appl.cat.ons as well as automated agents and systems may 
tnteract w.th enterprise applicat.ons and/or resources and the secunty arch.tecture as described herein 
Furthermore, a vanety of mformation resource identification schemes, such as by Uniform Resource Locator 
(URL), resource address, identifier or namespace designation, may be employed. However, for purposes of 
■Uustrat.on and not limitat.on. an exemplary interaction involvmg a browser and information resources 
.dent.fied by URL is described in detail. Nonethe.ess. based on the description herein, persons of ordinary 
skill rn the an wi.l appreciate a w.de vanety of configurations in accordance with the present invention in 
wh,ch non-browser Cents, automated agents or other systems interact w.th enterpr.se apphcations and/or 
resources and the secunty arch.tecture us,g any of a variety of information resource identification schemes. 

Focusing then on an exemp.ary browser-type client entity, browser 170 requests access to one or 
more of enterprise apphcations and/or resources (e.g., information resource ,9,) by present.ng an URL to 
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gatekeeper/entry handler component 110, which acts as a point of entry for client entities requesting access to 
appl.cat.ons and/or resources controlled by the security architecture. Gatekeeper/entry handler component 1 10 
rece.ves the request as a proxy for the requested resource. In some configurations, a combined 
gatekeeper/entry handler instance is provided, while in others, separate and/or multiple instances are provided 
w,h funct.ona.ly .dentica. mterfaces to other components of the security architecture. In some conf.gurahons 
mu.t.p.e usances of entry handler functionary (e.g.. tntercept.on of tnbound requests and co.lec.on of 
env.ronment informat.cn) are provided. For example, one or more .nstances for each of severa. connection 
types (e.g., d.alup, WAN, etc.) may be employed. One or more usances of gatekeeper funct.ona.ity (e g 
allowmg access for authorized requests and otherw.se denymg or initiating appropnate responsive act.on) may 
also be pr 0 v,ded. Configurations and funct.onal decompos.t.ons su.table to a particular environment and 
expected load requirements will be apprec.ated by persons of ord.nary skill in the art. 

Entry handler funct.onahty (e.g., in gatekeeper/entry handler component 110) ascertains much of the 
request.ng Cent's env.ronment .nformat.on. For example, for dial-up connect.ons, env.ronment informat.on 
such as hne speed and low-level l.ne encryption are ascertained. Add.t.ona. information, such as source 
number (e.g., from ca.ler id mformation or based on a callback configuration), signaling type (e g POTS or 
d.g.ta. ISDN), etc., may also be obtaured. For network connect.ons, similar envuonmen, .nformat.on (e g 
source network and/or node, V^a, Pr.vate Network (VPN) low-leve. encrypt.on, etc.) may. be obta.ned from 
.ncommg requests themselves or based on a part.cu.ar entry point (e.g., a particular router or port) More 
generally, gatekeeper/entry handler component 1 , 0 obta.ns and/or mau.ta.ns information such as connect 
locat.on (,f ascertainable), temporal information such as request time/date, sess.on start time/date etc 
( P referab,y in both the Cent entity, frame of reference and the secunty architecture or requested .nformat.on 
resource's frame of reference, if location is ascertainable), and client type and/or capabilities (e.g., browser 
type and Java Deve.opment Kit (JDK) level). In some conf.gurahons. information on line speed, origination 
pent (e.g., ms.de or outside of a corporate network), browser type, encrypt.on capability, number of hops 
latency, system type. etc. may be gathered. Such information is used m some configurations for mapping ' 
part.cular authentication mechanisms to trust levels and for authorization decisions. Env.ronment .nformat.on 
•s generaHy packaged into a data structure that is associated with a client sess.on. Other components of the 
secunty architecture may add additional client env.ronment information, such as authenricarion strength or 
current trust level. 



a session 

in some 



Gatekeeper functional.ty (e.g., in gatekeeper/entry handler component 1 10) checks whether 
.s already associated w.th the incom.ng request. Although other techniques are possible in some 
configurations in accordance with the present invention, gatekeeper/entry handler component 1 10 checks for 
the presence of a session token in the incoming request. Use of session tokens is described in greater dec.il 
below; however, in short, a session token may be any data supplied to the client entity for use in unique.y 
.denttfymg an associated sess.on. In general, preferred session token unp.ementations are cryptographically 
secured and include facilities, such as expiration or mapputg to a part.cu.ar connection, to ..mi, risk of rep.ay 
attack and/or spoofing. Some session token imp.ementat.ons may encode session, principal, and/or trust .eve. 
.nformat.on. Some session token implementations may emp.oy cookies, URL encoding, or other surular 
techniques for binding to incoming requests. 



WO 01/1 1452 

PCT/USOO/20931 

- II - 

In some configurations, session tokens are employed to facilitate session continuity and to allow the 
security architecture to associate prior authentication of login credentials with an incoming access request. In 
one utilization, session tokens are issued to client entities as pan of an interaction with the security architecture 
and are thereafter presented with access requests. In some configurations, new session tokens (each 
corresponding to a single session) are issued to client entity on each credential level change. In other 
configurations, a session token may remain the same even as credential levels are changed. Session continuity 
means the ma.ntenance of coherent session state across one or more interactions between an entity and an 
Information environment. 

Components of sess.on state (e.g., in some configurations, principal id, session id, authent.cated trust 
level, group ids and/or roles, creat.on tune, expirat.on time, etc.) are maintained or advanced throughout the 
duration of a session. Typically, aspects of session state are represented internally by the security architecture 
and a sess.on token (e.g., a session id encoded in a cryptograph.cally secured session token) allows the security 
architecture to reference into the internal representat.on. However, in some configurations, at least some 
aspects of session state may be represented or duplicated in the session token. For example, a principal id and 
current trust level are encoded in one realizat.on of a cryptograph.cally secured session credential and 
associated sess.on token or cookie. In general, a variety of facilities, such as cookies, can be used to mauuatn 
state across a ser.es of protocol interactions, such as HTTP transactions, that do not otherwise support 
persistent session state. 

Referring again to FIG. 1, if a session token is present in the incoming request, gatekeeper/entry 
handler component 1 10 resolves the token to a sess.on object. Alternatively, if no session token is present or if 
a session token is invalid, gatekeeper/entry handler component 1 10 establishes a new session (2). In an 
exemplary configuration in accordance with FIG. 1, session management component 160 allocates a new 
session and suppl.es associated default sess.on credentials (2) based on the requested information resource and 
environment information. Note that a session is created irrespective of authentication status or identity, 
although some implementations may refuse to even allocate a session based on particular information resource 
requests and/or environment information. Given a session object, which may be resolved from a received 
session token or newly allocated, gatekeeper/entry handler component 110 interacts (3, 4) with authorization 
component 140 to determine whether the requested access is authorized. For some requested accesses and 
security policies (e.g., anonymous ftp access to certain archives), even a session without authenticated login 
credentials (trust level=0) may be authorized. For others, a more substantial trust level may be required. 

Gatekeeper/entry handler component 1 10 supplies authorization component 140 with an identifier for 
the requested resource (e.g., the requested URL) and an identifier for the associated session. Preferably, the 
associated session identifier is cryptographically secured (e.g., as a signed session credential). In some 
configuranons. the signed session credential is obtained from the corresponding session object. In the case of 
a pre-existing session, the signed session credential may be obtained using a received session token. In any 
case, authorization component 140 receives (3) the requested resource and session identifiers and responds (4) 
in accordance with the mis. level requirement of the requested resource. In configurations for which 
sensitivity to a changing environment is desired, env.ronment information may also be supplied to 
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authorization componen, 140. In an exemplar configurafion. authorizat.on component 140 responds with an 
ALLOW, REDIRECT, or REFUSE response based on the sufficiency of a curren, trus, level In some 
configuranons, authorization componen, 140 dynamically calculates a curren. trus, level based on the s.gned 
sess.on credentials and environment informat.on. In others, authonzation componen, 140 may base its 
ALLOW. REDIRECT, or REFUSE response on a •■curren," trust .eve. previously associated with the s.gned 
sess.on credent.a.s. General.y, an access request with sufficien, curren, tms, .eve. is ALLOWED and 
forwarded (14) withou, further authenricat.on. An au.horrzat.on request w.thou, proper parameters (e g 
w,thou, a specified information resource or wi,hou, a properly secured sess.on credentia.) may be REFUSED 
Au,ho„za,,on reques.s associa,ed with a c.ien, ent.ry that has been blacklisted or for a resource for which the 
assocated c.,en, entity cannot be authenticated us.ng any avai.ab.e method ,o ach.eve the requ.red trus, .eve. 
nray also be REFUSED. For examp.e, a given secur.ty policy and assocated ^ .eve, mappings may d.c.ate 
a REFUSE response in response to an access reques, to a sens.t.ve resource (such as financial da*) by any 
Cent enfty (even a browser supplying the digital certificate for the CFO, and therefore presumably opera.mg 
on beha,f of the CEO) if the access reques, is rece.ved over a d.a.-up line and ongma.es fro m an unknown 
number or is received outside of working hours. 

In general, there is an .mplic.,, base level of env.ronmen, inherent in an authenticated trust level 
however, m some configurat.ons, a part.cu.ar authorizat.on transaction may dig deeper into environment ' 
■nfonnauon before respondmg. For examp.e, in configurations prov.dung .o g -u P capabilities, an authorization 
serv.ee w,.| typical.y redirect to a login serv.ee if the trus, .eve. assocated w.th current session credent.a.s is 
utsufficen, for a requested access. However, for sensit.ve applications in such a configurat.on, an ,nadequa,e 
trus, .eve. may resu.t in a REFUSED message rather than a .og-up REDIRECT dependmg on the particular 
security policy implemented. 

A REDIRECT response ,s used ,o forward the access request ,o login componen, 120 so tha, 
sufficen, log.n credent.a.s may be obtained and authent.cated to achieve the required trus, level for the 
requested access. Note tha, m some configurations, both initial login credentialing and credential upgrade are 
prov.ded using Ore REDIRECT facility. In response to a REDIRECT response (4), gatekeeper/entry handler 
component 1,0 red.rects (5) browser 170 to login component 120. In one configuration, gatekeeper/en^ 
handler componen, 110 issues a clien.-side redirect via HTTP location d,rec,ive to forward the request to log.n 
component 120. Parameters such as requtred trus, level, requested URL and credential passmg method can be 
encoded in the red.rec, URL and supplied (6) by browser 170 to login componen, 120. Alternatively some 
parameters can be passed (5A) directly (e.g., through a HttpSess.on object) although a stateless configuration 
is preferred. 

A sess.on token is passed ,o browser 170 in conjunction with the red.rec, (5) to .ogin componen, 120 
Based on the descript.on here.n, persons of ordinary skill in the art will appreciate a number of sukab.e 
mechamsms for pass.ng the session token, mc.ud.ng those based on cook.es and URL encoding Preferably 
mechamsms employed are based on facilities prov.ded by commerc.al.y ava.lable browsers (e g in 
accordance with HTML 3.x, 4.x or other de-facto standards), a.though customed or p.ug-in fac.ities for 
recevmg and supplying session token may be employed. In one suitable configuration, the sess.on ,oken is 
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cryptographically secured and encoded in a cookie placed at browser 170 usurg a set cook.e directive 
embedded in the redirect. Other configurations may use a less persistent session identificat.on method, such as 
passing an identifier or session token in the redirect URL without storage at browser 170. Still other 
configurations may transmit a session token, a session credential, or identifier such as a session handle for 
storage in a med.um such as a smart card. In configurations prov.duig credential upgrade, pers.stent session 
ident.ficat.on methods are generally preferred, even for a no, yet authenticated Cent entity, for consistency of 
approach. Note that although the identity of the client entity may not be authenticated to a sufficient level of 
trust, the redacted request mc.udes a session token that a, .east ident.fies the sess.on. Other configurations 
may onu, the bind.ng of sess.on tokens to sess.ons of no, ye, authenticated cl.en, entities, though with some 
increase in complexity of login component 120. 

Browser 170 sends (6) login component 120 a new access request us.ng the URL specified in the 
rednec, from ga.ekeeper/entry handler component 1 , 0. In configurations empioying cookies as a med.um for 
passmg sess.on tokens, the new access reques, will include the cook.e and therefore the session ,oken Note 
tha, .n configurat.ons in which the security architecture controls access to resources ,n several domains care 
shou.d be exercised ,o se.ec, a tag or tags for the cookie such tha, ., will be prov.ded through normal operation 
of the browser in subsequent accesses to any of the several domains. Persons of ordinary skill in the art will 
a P prec.a,e su.tab.e tagging techniques, inc.uding the use of multiple cook.es. Login component 120 receives 
the access reques. and determines an appropriate authentication scheme based on mapping rules tha, identify 
those authent.cation schemes which are sufficient to ach.eve a given trust level. Preferably, the mappmg rules 
are a function of envuonment information. In some configurations, mapping rules are implemented as fuzzy 
sets wherein acceptable authentication schemes are a function of required trust level and environment 
information. In this way, environment affects the set of authentication schemes sufficient to meet a trust level 
requirement. 

Generally, mapping rule logic is typically evaluated before a user is challenged to authenticate 
Mapping occurs as a function of session environment and particulars of the information resource for which 
access ,s requested. By evaluating the minimum trust level required by the target of an access request, a 
serv.ce (e.g., a login service such as provided by login component 120) derives a list of potential 
authentication methods. The service then checks current session environment against the al.owed environment 
states for each potential authentication method to trim the list further. If there is no particular resource for 
wh,ch access is being requested (e.g., if a user jumps straight to a S ,g n - 0 „ pag e without requesting an access) 
the serv.ce w.ll proceed according to the lowest level of trust available consistent with session environment. 
Other configurations may employ differing default behaviors. 

In some configurations, login component 120 queries (7) authorization component 140 to identify the 
set of authentication schemes tha, meet or exceed the required trust level given a current envuonment In 
other configurations, the mapping is performed by login component 120. In either case, login component 120 
suppl.es (9) mformation to browser 1 70 to allow the user to select from the suitable authent.cation schemes 
and to provide an associated login credential. In some configurations, .ogin component 120 suppl.es browser 
170 w.,h a login page (e.g.. HTML) that prompts the user for an appl.cation specific user ID and a choice of 
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authentication schemes. Interactions with browser 170 depend on the se, of credential types that if 
authenticated, wou.d be sufficient to meet the trust level requirement for access to the requested resource For 
example, ,f more than one type of credential would be sufficient, login component 120 may tnteractive.y allow 
a user to select from amongst the credential types (e.g.. using any HTML-based dialog). Once a particular 
credent.a. type has been selected, login component 120 .nteracts with browser 170 to obtain an tnstance of the 
login credential to establish the identity of the browser user. 

Some credential types (e.g., usemame/password patrs. onetime passwords, en.gma challenge etc) 
may be obtained ^ an mterac , ive ^ fa ^ ^ ^ ^ ^ ^ ^ ^ 

HTML fon. browser 170 POSTs form contents back to login component ,20. Others (e.g., digital cert.ficates) 
may be supphed (10) for the client entity from browser ,70. or ,„ some configurations, may be obtained from 
or v,a an agent or certificate authonty. A personal digital certificate (such as those issued by Verisign™ 
Thwate. Entrust or other certificate authority) may be obtained from a browser 170 us.ng an HTTP certificate 
request. Although credentials may be transacted in a variety of ways, credentials are typical.y obtained from a 
user. Typically, the obtaining is indirect by asking the user's browser to complete the negotiation process In 
such configurations, certificate-based authentication may be transparent to die user. In some configurations 
further authentication can be performed by usmg information encoded within the certificate to query a 
certificate authority for current status or a lookup to an authentication database may be performed for more 
detailed requirements, .n an exemplary configuration, the more detailed information could relate to session 
environment or could force an additional name/password authentication as par, of the certificate authentication 
cha.n. m a particular implementation such facilities can be provided by mapping rule encodings that require 
successful authentication us.ng multiple authentication methods to achieve a given trust level. 

Once login credentials have been obtained by login component 120. they are supplied (1 1) to 
gatekeeper/entry handler component 110 for authentication. In configurations in which both gatekeeper/entry 
handler component 1,0 and login component 120 have access to a shared object such a, the HttpSess.on 
object, login credential passing via the shared object is suitable. In other configurations, an HTTP POST may 
be employed. In an exemplary configuration, the particular credential passing method is selected as part of the 
ongma. HTTP redirect (e.g.. encoded in the redirect URL) although other configurations need no, allow for a 
selection or may employ other facilities for selection of a credential passing method. 

Login component 120 also passes control of the access request back to gatekeeper/entry handler 
component 110. In an exemplary configuration, login component 120 .ssues a new HTTP request (1 1) 
specifying the originally requested URL. which has been stored in the HttpSession object As before 
gatekeeper/entry handler component 1 ,0 receives the request. Gatekeeper/entry handler component 110 
extracts the login credentials from the request or from the HttpSess.on object and passes (12) the login 
credentials to authent.cation component ,30 for authentication. Authentication component ,30 authenticates 
the login credential, and if successful, queries (13) identification component ,50 to establish a correspondence 
wth a se, of enuty descriptors that uniquely identifies the requesting entity. In an exemplary configuration 
enuty descriptor types include: entity id. system id (e.g.. name/password), certificate, enigma id. smartcard ' 
token, name/address, and phone. One or more of values may uniquely identify an entity and one or more 
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entity descriptor types may support multiple values (e.g., multiple digital certificates, name/password pairs or 
phone numbers per identity). Once the requesting entity has been .dentified (14), session parameters are 
updated (15) and session management component 160 supplies (16) session credentials. Preferably session 
credent.a.s are dig.ta.ly-s.gned or otherwise cryptographica.ly secured and returned (1 7) to gatekeeper/entry 
handler component 110. 

Gatekeeper/entry handler component 110 again suppl.es (18) authorization component 1 40 with an 
.denufier for the requested resource (e.g., the requested URL) and an .dent.fier for the assocated sess.on (e g 
the s.gned sess.on credentials, authonzation component 140 responds with an ALLOW REDIRECT or 
REFUSE response based on the suffic.ency the sess.on credent.a.s (and under.yutg authent.cat.on of logo, 
credent.a.s) for the trust level requ.red for the requested access. Log.n credentials should now be sufficient for 
access to the requested resource and an ALLOW response ,s supplied (19) by authonzation component 140 
Gatekeeper/entry handler component 110 prox.es the requested access (20, 21) to mformation resource 191 
and streams (22) results back to log in component 120. Logrn component 120, in turn, streams (23) resu.ts 
back to browser 170. 

In some embodunents in accordance w.th the present invent.on, sess.on continuity is facilitated by 
su PP .y.ng a sess.on token to browser ,70. For examp.e in one configuration, login component 120 supplies a 
sess.on token using a set cookie d.rective encoded w.th the results streamed (23) back to browser 170 In 
response, browser 170 stores the cook.e usmg a tag (typically a fi,ename encodmg). Browser 1 70 supp.ies the 
cook,e (and the sess.on token) w.th subsequent access requests based on a correspondence between the tag and 
the requested resource. Typica.ly, the correspondence ,s based on the second-.eve. domaut (e.g., sun com) in 
wh.ch the requested resource is hosted, although nth-level domains or other resource identification and session 
token assorting schemes may be employed. In configurations in which the security architecture controls 
access to mult.ple domains across which a spanning single sign-on .s desired, mult.ple cookies may be 
employed. 

Although the encoding of session tokens using cook.es is presently preferred, rn part because cook.e 
fac.ht.es are widely supported and reasonably well accepted, other facil.ties may be employed to establish 
sess.on continu.ty. For example, altemat, ve URL encodutgs and/or custom or plug-in support for sess.on 
•denufier rece.pt, storage and supply may be employed. Also, some configurations may employ lower-level 
sess,on .dentifiers, e.g., as prov.ded by a particular connect.on type such as trusted caller id mformation or as 
assocated w.th a low-.evel fine encryption or virtual pnvate network infrastructure. As such facilities are 
likely to be connect.on-type spec.fic, i, is env.s.oned that they may be used in conjunction with other session 
•denufier facilities described above, e.g.. sess.on tokens encoded in cookies. ,n one configuration, the un.que 
Ethernet MAC address assocated with a network mterface card may be employed as a session hand.e The 
MAC address .s then used to associate w.th a particular set of session credentials maintained by a central 
authority. In general the representation of a session handle can take may forms. 

Referrmg again to FIC. 1. subsequent access requests (e.g., access request 1 A) mclude a prev.ously 
ass.gned sess.on token. As described above, gatekeeper/entry handler component 1.0 uses the session token. 
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if provided to resolve a session object containing session credentials, and to determine whether previously 
authenticated credent.als are sufficient for the requested access. As described above, authorization component 
140 may be queried using session credentials and an identifier for the requested resource to determine 
sufficiency of previously authenticated credentials. In some configurations, sufficiency is determined using 
trust level mappings as described above. Depending on the information resource to wh,ch access is requested 
and ,n some configurations depending on current session environment mformation, access request 1 A may or 
may no, have associated previously authenticated credentials sufficient to support the requested access In the 
case of an access request 1 A having a trust level requirement commensurate with previously obtained and 
authenticated credent.als (i.e., an access request for which no additional credentials need be obtained via login 
component 120), the access request is prox.ed (20) and results (21) are streamed directly (23A) back to 
browser 1 70. In some configurations, gatekeeper/entry handler component 110 supplies an updated session 
token us,ng a set cookie directive encoded with the results streamed (23A) back to browser 170. An updated 
session token, if supplied, resolves to the same session object as the session token replaced. For example in 
some configurations, both session tokens encode a same session hand.e, although other aspects associated with 
session token security such as expiration may be updated. In other configurat.ons. results (21) are sneamed 
(23A) back to browser 170 without an updated session token. In such configurations, the previously supplied 
session token remains valid until expired or otherwise invalidated. Some variations may employ a session 
token refresh interval. 

Depending on the information resource to which access is requested, previously obtained and 
authenticated login credentials may be insufficient for the trust level requirement associated with requested 
access 1A. As before, authorization component 140 supplies gatekeeper/entry handler component 110 with an 
ALLOW, REDIRECT or REFUSE response based on the trust .eve, accorded based on the previously 
obtained and authenticated login credentials and on the trust level requirement associated with requested 
access 1A. Advantageously, authorization of individual access requests is streamlined by the encoding of trust 
level ,n a cryptographically secured session credential or token. In the case of insufficient credentials, a 
REDIRECT response is supplied and gatekeeper/entry handler component 1 10 again redirects (5) browser 1 70 
to logm component 120. Additional log.n credentials are obtained as described above with reference to initial 
credentials. Upon successful authentication, access request is proxied (20) and results (21) are streamed (23A) 
back to browser 170. 

Preferably, gatekeeper/entry handler component 110 supplies an updated session token us.ng a set 
cookie directive encoded with the results streamed (23A) back to browser 1 70. An updated session token if 
supplied, resolves to the same session object as the session token replaced. As a result, session state (including 
e.g.. .dennty mappings, authorizations, roles, permissions, environmental variables, etc.) is maintained through 
the credential level change. However, in the case of a credential upgrade, the session object now encodes a 
login credential successfully authenticated to achieve a higher trust level. In one advantageous configuration 
the achieved (higher) trust level is encoded in a cryptographically secured session token representation as a ' 
cookie streamed (23A) back to browser 1 70 with results (21). 
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FIG. 2 illustrates operation of an exemplary security architecture providing a single sign-on facility 
w.th trus, level mapping to authentication requirements. As before, an access request is received (201) from a 
chent enuty. If the request does not conta.n a sess.on .dent.f.er (e.g.. a sess.on key or token) or if the request 
can othenv.se be reliably associated with a session maintained by the secunty architecture, a new session .s 
created (202). A trust level requ.remen, is determined for access to the requested resource in the context of the 
requestmg sess.on environment. In some configurates, as described above, the deterrrunation is performed 
by an authorizat.on serv.ce such as authorization component 140. G.ven a trust level requirement current 
sess.cn credentials are eva.uated (203) in the context of sess.on env.ronmen, information to deterrrune whether 
the prev.ou.ly suppl.ed logm credentials are sufficient to ach.eve the requ.red trust level. In one advantageous 
realtzanon of session credentials and tokens, a cryptograph.ca.ly secured encod.ng of trus, .eve. allows 
authonzation to be confirmed without involvement of an authenticate service (e.g., with reauthent.cation of 
logo, credentials). In the case of a newly created (202) sess.on. the authonzat.on ev.denced by sess.on 
credentials w.ll ryp.ca.ly be insufficient, although some secur.ty policies may allow anonymous access to 
certain resources. 

For a pre-ex.stu.g sess.on, i.e.. for an access request that can be rel.ably assoc.ated with a pers.sten, 
sess.on by a cryptograph.cal.y secured sess.on token or otherw.se. session credentials may or may no, be 
sufficent for access to the currently requested resource. For examp.e. after a first access, the ident.ry of an 
ent.ty accessmg resources controlled by the security arch.tecture wi.l be authenticated to a trus, .eve. sufficient 
for that access. Depending on the trus, level requ.rements of a subsequen, access and. in some configurations 
depending on then current trust .eve, mapping rules and envtronment information, the level of trus, associated 
wth a current session (e.g.. as ev.denced by current sess.on credentials) may or may no, be sufficient for the 
subsequent access. In situations for which a current level of trust (e.g.. resulting from prior authent.cation of 
login credentials for an ent.ty associated w.th the session) is sufficient for later access to the same or to another 
mformanon resource, access is allowed without additional authent.cation. For example, in some security 
architectures in accordance with the present invention, the security architecture proxies (204) the request to the 
requested .nformarion resource and streams (205) a resulting response back to the requesting client entity. 

As described elsewhere herein, sufficiency of current session credentials is determined us.ng mapping 
nt.es that, in some realizarions. tnc.ude environment informat.on. In genera., current session credential may 
be insufficient (1) because the .dentity of the requesting client has not yet been authenticated (e.g in a firs, 
access situation). (2) because of a higher trust leve. requirement for the requested access, or (3) because of a 
change u, mapptng rules or environment that causes a previously sufficient credenua. no longer be sufficient 
for a part.cu.ar trus, level. Whatever the reason for the insufficiency, a request correspond,^ to a sess.on and 
chent ennty tha, is insufficiently authenticated, and that is therefore not authorized, is passed to a facility for 
obtaining credentials of a type mat. if authenrica.ed. will support the required trust level. 

Typ,cally. session credent.als and/or an associated session token encode an expiration time (see 
descnpnon. above, of FIG. 4). m such configurat.ons. a previously suffic.en, sess.on credenua. .s .nsufficien, 
after .ts exptrat.on. .„ some configurations, session credentia.s are periodically refreshed by reauthent.cation 
of ,he underlying .ogin credent.als. For examp.e, in one imp.ementation. a presented sess.on token indicat.ng 
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expiration in less than five (5) minutes causes the security architecture to reauthenticate (not shown) 
underlying login credentials stored in a corresponding Sess.onObject (e.g.. under the private key of 
authentication component 130). Reauthent.cat.on typ.ca.ly results in a new sess.on credential and associated 
trust .eve.. Depending on then instant mapping rules, the associated trust level may or may not be sufficient 
Also, reauthenticarion may fail if the login credentials have been invalidated, revoked or if the login 
credentials have ex p,red. Assuming tha, reauthent.cat.on of login credentials is successful, updated sess.on 
credentials are issued, for example, by authentication component 130 and supp.ied (e.g., as a cookie encoded 
session token) to the client entity e.g., browser 170). 

Referring again to FIG. 2, a request corresponding to a session no, authorized for a requested access 
.s redirected (206) to a credential gathering serv.ce (e.g., login component 120). The credential gathering 
serv.ce receives (207) the redirected access and obca.ns (208) a trust level requirement for the requested 
access. In some configurations, the trust level requirement may be passed with the redirected access or 
otherw.se associated with the redirected access, in others the trust .eve. requirement may be re-obta.ned from 
an author.zat.on serv.ce such as author.zat.on component 140. A trust level requ.remen, is mapped (209) to a, 
least one authentication scheme sufficient to achieve the requirement based on current trust level mappings 
and, if employed in the mapping rules, based on current environmen. unformat.on. Assuming that at least one 
authentication scheme is available that, if successful, will support the required trust level, login credentials of 
that type are obtained (21-0) for the entity and authenticated (211). Some credential types (e g 
usemame/password pans, onetime passwords, enigma challenge, etc) may be obtained through an interactive 
process ,„ which a principal (e.g., a human user) suppl.es the credent.al(s) entry in an HTML form and POSTs 
form contents back to the credential gathering serv.ce. Others (e.g., certificates) may be obtained for the client 
entity from an agent or authority. For example, a personal digital certificate (such as those issued by 
Vens.gnTM, Thwate, Entrust or other certificate authority) may be obtained from a browser using an HTTP 
certificate request. In some configurations, a choice of credential types may be provided and user may select 
from a set of credential types sufficient for the requested access. Once appropriate login credentials have been 
obtamed and authenticated, the session corresponding to the requested access is updated (213) to reflect the 
new authenticated session credentials. The now sufficiently authorized request is proxied (204) and results are 
streamed back (205) to the requesting client entity. Updated or refreshed session credentials are typically 
supplied as a session token (e.g., a cookie) encoded with the streamed results. 

FIG. 3 illustrates interactions between functional components in an exemplary functional 
decomposition of a security architecture. An on-line order processing transaction is exemplary and functional 
boundanes are merely illustrative. Based on the description herein, a wide variety of suitable enterprise 
tnformation environments and functional decompositions in accordance with the appended claims will be 
appreciated by persons or ordinary skill in the art. 

In the configuration of FIG. 3, application and central security portions (321 and 322, respectively) of 
the security architecture are illustrated. Of note, functional components of application security portion 321 are 
typically hosed as services on a first server environment, while functional components of central security 
portion 322 are hosted as services on a second server environment. In this way, most interactions amongst 
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funcuonal components occur within a stngle server envuonment and do not require network transactions In 
the configuration of FIG. 3, credenrials associated with a cal.ing component (e.g., framework credentials 
assocated w,th apphcation security framework 303 or application credentials assocated with order 
management serv.ce 312) are used ,o establish sufficent authorization for network transactions Other 
configurates may be employed, however, the relatively small number of network transactions (e g 
authent.cation transaction 331 and opt.ona. value pass.ng transacts 332, tends to improve performance of the 
secunty arch.tecture. Of note, authent.cat.on txansacrion 331 need only be performed on login credential 
authenttcat.on (e.g., a, initial sign-on or credent.a. upgrade) or reauthent.cated (e.g., to refresh sess.on 
credent ia .s). Value passtng transaction 332 provides an opnona. facility for passmg values amongsr mulriple 
components of a distributed a PP l,ca,,on (e.g., a disputed .mp.ementat.on of order management serv.ce 312) 
wherem apphcation credent.a.s are used ,o mediate storage and retrieva. of values ,n a central registry. 

User 301 mteracts with browser 302 to place an order w„h order management serv.ce 312 An 
apphcauon securiry framework 303 receives an access request including the order and, operating in 
co^ncon with a variety of other serv.ces, prov.des a single s.gn-on facility substantially as descnbed above 
If the order does no. mclude a session token or cannot be otherw.se associated w.th corresponding valid 
sess.on credent.a.s, then sess.on credentials are obtatned. As illustrated in FIG. 3, sess.on credent.a.s are 
obtaured using login credent.a.s (e.g., a usemame/password pau, a dig.ta. certificate, etc.) Typically, an access 
request w.thout sess.on credentia.s wil. not have assocated .ogin credent.a.s. As a result, and defau.t login 
credenuals (e.g.. ident.ty=anonymous) are used durmg initial phases of a single s.gn-on process. Nonetheless 
m some configurates, logut credent.a.s may be provided w.th an initial access request. More typically an ' 
mma. access request is received by applicat.on secunty framework 303 w.thout sess.on credentials or without 
pnor presentation and authentication of login credent.a.s sufficient to access the requested resource In 
response to credential gathering operations, a subsequent request is made with login credenrials tha, purport to 
be sufficent, if authenticated, to meet the trust ,evel required for access to order management service 312 In 
such a case, session credentia.s are obtained by passing login credent.als to a central security framework 304. 

Authorization of apphcation security framework 303 for access to components of the central security 
pomon 322 is checked by query to central authorizat.on serv.ce 306. Assummg that framework credentia.s 
ev.dence sufficent authorization, login credentials are authenticated by central authentication service 307 
Centra, authent.carion service 307. m turn, mteracts with centra, princpa. reg.stry 310 to establish the identity 
and group membership of user 301 and with centra, sess.on registry 31 1 to create a persistent session for 
subsequent accesses by user 301. Particu.ars of the request are .ogged to centra, audi, service 308 and if 
authent.cat.on was successful, session credenrials are returned to appl.carion security framework 303. ' 

S.gned sess.on credentials are presented to application authonzation service 313 together with an 
•denufier for the requested resource and optionally with an .dent.fier for a part.cu.ar function or facility of the 
requested resource. In response, applicat.on authonzat.on service 313 checks the authorization of the principa. 
(e.g.. of user 301) associated with the sess.on credent.a.s to access the requested resource. Application 
authonzation service 313 mteracts w.th apphcation resource registry 3.4 to identify trust .eve. requuements 
for the requested resource (and in some configurations, for a panicu.ar function or facility of the requested 
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resource) and determines the sufficiency of a current trust level evidenced by the sesston credential. Note that 
trust level is assessed by inspection of the session credential and without interaction with an authentication 
service. In some configurations (e.g., as illustrated in FIG. 3), group membership is also evaluated as part of 
the authorization check. 

If the signed session credentials indicate that the requesting entiry. e.g., browser 302 on behalf of user 
301. is sufficiently authorized to access order management service 312. a CreateOrder request is passed to 
order management serv.ce 312 and order processing proceeds in accordance with normal handl.ng thereof. 
Additional accesses may be requ.red, e.g., to select delivery options or to confirm some aspect of the order. 
Assuming that the additional accesses do not require a higher trust level, they will be passed to order 
management serv.ce 312 based on the correspondence of sess.on credent.als with trust level requirements. 

If an exception is thrown due to insuffic.ent authorization, e.g., ,f the s.gned sess.on credentials do 
not indicate that the requesting entity is sufficiently authorized to access order management service 312, a 
logui credent.al gathering process is initiated. Based on the required trust level and on rules that encode the 
sufficiency of authent.cat.on schemes, a logui credent.al is obtained from user 301 and/or browser 302. The 
obtained login credent.al is of a type that, ,f authenticated, .s suffic.ent to meet the trust level requirement for 
access to order management service 312. Aspects of an exemplary credent.al gather.ng process are described 
m greater deta.l above. However, as an example, FIG. 3 illustrates the obtaining of a username/password pair 
Once logui credentials are obtatned, they are passed to central security framework 304 (as descr.bed above) for 
authenticatron by central authentication service 307 so that session credentials can be obtained, the requested 
access can be authored, and the order process.ng .nit.ated. Signed session credentials, typically embodied as 
a cryptographically secured session token that may be stored as a cookie, are passed back to browser 302 with 
results of the requested access. In this way, subsequent access requests are identified as part of a session and 
authorization may be quickly confirmed without unnecessary re-authentication. 

Exemnlar y Implementations 

In an exemplary embodiment, at least some of the above-described components are implemented as 
sen-lets executable in the context of a commercially-available web server environment. For example, the 
Java™ Embedded Server (JES) architecture with extensions for certificate handling, HyperText Transfer 
Protocol (HTTP), Simple Network Management Protocol (SNMP), Secure Sockets Layer (SSL), extensible 
Markup Language (XML) grammar processing and security Access Control List (ACL) support available from 
Sun Microsystems, Inc. is one suitable environment. Java and all Java-based marks and logos are trademarks 
or registered trademarks of Sun Microsystems. Inc. in the United States and other countries. 

In general, the descript.on herein is focused on aspects of a security architecture, rather than on 
peculiarities of a particular implementation envnonment. It is envis.oned that security architectures in 
accordance with the teachings of the present invention may be implemented in the context of many 
commercially-available networked .nformation service environments, including web server environments, as 
well as in custom environments and environments that in the future will be developed. However, to facilitate 
an understanding ofbroad concepts using a specific exemplary environment, and without limitation, the 
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description herein may include terminology specific to the Java Embedded Server (JES) archil 
Nonetheless, based on this description, persons of ordinary skill in the art will appreciate implementations 
suitable for other environments. The scope of the invention, as defined by the claims that follow, is not limited 
to any specific implementation environment. 

While the invention has been described with reference to vanous embodiments, it will be understood 
that these embodiments are illustrative and that the scope of the invention is nol limited to them. Many 
variations, modifications, additions, and improvements are possible. For example, the set of authentication 
schemes described herein is illustrative and embodiments in accordance with the present invention may 
include others, including those that may be hereafter developed. If employed, rules mapping trust levels to 
authentication schemes may be encoded in a variety of ways depending on the particular implementation. In 
general, such mapping rules may be encoded as static or dynamic table associat.ng trust level to authentication 
schemes. Alternatively, mapping rules may be encoded as predicates or in other declarative forms. Mapping 
rules may be encoded in a weighted logic or fuzzy set form. Additionally, particular mappings may depend 
env.rotiment information. Furthermore, evaluat.on of mapping rules may be performed m a variety of 
functional components such as an authorization service, a credent.al gathering service or a gatekeeper. 
Session conrinuity may be provided using cryptographically secure session tokens passed as cookies or by 
other mechanisms. 

In some configurations, a session token is a compact encrypted representation of at least selected 
contents of a session credential. Other compact representations correspondmg to a session credential may be 
employed. Alternatively, the same representation of session credentials may be employed both within the 
security architecture and outs.de the security architecture (e.g., at a browser or other chent). Suitable contents 
of a session credential (and session token, if employed) will be appreciated by persons of ordinary skill in the 
art based on the description herein of specific examples. 

More generally, plural instances may be provided for components described herein as a single 
mstance. Finally, boundaries between various components, serv.ces, servlets, registries and frameworks are 
somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative 
configurations. Other allocations of functionality are envisioned and may fall withm the scope of claims that 
follow. Structures and funct.onality presented as discrete components in the exemplary embodiment(s) may 
be unplemented as a combined structure or component. These and other variations, modifications, additions, 
and improvements may fall within the scope of the invention as defined in the claims that follow. 
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WHAT IS CLAIMED: 

1 A session credential for use in a security architecture controlling access to one or more 
information resources, the session credential comprising: 

a principal identifier uniquely identifying a principal; and 

an encoding of authorization accorded by the security architecture after prior authentication of a login 
credential corresponding to the principal, 

the principal identifier and authorization encoding being cryptographically secured and allowing the 
security architecture to evaluate sufficiency of the authorization for access to the one or 
more information resources without re-authentication of the login credentials. 

2. A session credential as in claim 1, 

wherein the cryptographic securing includes encryption of at least the principal identifier and 
authorization encoding using a private key associated with the security architecture. 

3. A session credential as in claim 1, further comprising: 
an encrypted portion and an unencrypted portion; 

the unencrypted portion allowing contents of the session credential, including the principal identifier 
and authorization encoding, to be read without possession of a key; 

the encrypted portion being encrypted with a private key associated with the security architecture and 
allowing authenticity of the unencrypted portion to be confirmed using a public key 
corresponding to the private key. 

4. A session credential as in claim 3, 

wherein the encrypted portion is supplied external to the security architecture as a session token that 
uniquely identifies a corresponding persistent session maintained by the security 
architecture. 

5. A session credential as in claim 4, 

wherein the session token is encoded as a cookie supplied to a browser; and 

wherein the cookie is included with access requests made by the browser targeting the one or more 
information resources. 

6. A session credential as in claim 3, 

wherein the cryptographic securing is by a private key possessed substantially only by an 

authentication component of the security architecture; and 
wherein authenticity of the cryptographically secured principal identifier and authorization encoding 

is verifiable by components other than the authentication component using a public key 

corresponding to the private key. 
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7. A session credential as in claim 1, 

wherein the cryptographic securing includes a digital signature encompassing at least the principal 
identifier and authorization encoding and thereby allows authenticity of the principal 
identifier and authorization encoding to be confirmed using a public key. 

8. A session credential as in claim 1 , further comprising: 
an expiration encoding. 

9. A session credential as in claim 1, further comprising: 
a session identifier. 

10. A session credential as in claim 1, further comprising: 
a group identifier. 

1 1. A session credential as in claim 1, further comprising: 
one or more additional elements selected from 

an expiration encoding; 
a session identifier; and 
a group identifier, 
the one or more additional elements also cryp ^graphically secured. 

12. A session token for transfer between a client entity operating on behalf of a principal and a 
security architecture controlling access to an information resource, the session token comprising: 

a principal identifier uniquely identifying the principal; and 

an indication of authorization level accorded by the security architecture after prior authentication of 
a login credential corresponding to the principal, 

the principal identifier and authorization level indicanon bemg cryptographically secured and 

allowing the security architecture to evaluate sufficiency of the authorization for access to 
the information resource without re-authentication of the login credentials. 

13. A session token as in claim 12, encoded as a cookie stored at a browser. 

14. A session token as in claim 12. placed a, a browser m response to a se, cookie directive by the 
security architecture. 

15. A session token as in claim 12, encoded for transfer to the client entity. 

.6. A session token as in claim 12, encoded in a communication medium as mforma.ion in trans,, 
between the client entity and the security architecture. 
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1 7. A session token as in claim 1 2, 

wherein the client entity includes a browser; and 

wherem the session token is embodied as a cookie supplied to the browser by the secunty architecture 
and tncluded with an access request made by the browser targenng the information resource. 

1 8. A method of providing authonzat.on verificahon m a security architecture controlling access to 
or more information resources, the method comprising: 

obtain.ng a login credential and authent.cating a principal thereby; 

issuing a cryptographically secured session creden.ial encoding a, leas, an identifier for the pnncipa. 
and a first authorization accorded based on the authenticating; and 

for plural requests for accesses to the one or more of the information resources, selectively a.iowmg 
access based on sufficency of the first authorization encoded by the cryptographically 
secured session credenrial for access to the one or more of the informa.ion resources 
wherein the selective allowing ,s performed w.thout additional login credential 
authenticating. 

19. A method as in claim 18, further comprising: 

digitally signing the session credential prior to issuance thereof; and 

prior to the select.ve allowing, verifying authent.ctty of the principal identifier and firs, authorizat.on 
encoding using a public key. 

20. A method as in claim 18, further comprising: 

encrypting at least the identifier for the principal and the first authorization using a private key 
the .ssued cryptographically secured session credential including at least the identifier for the ' 

principal and the first authorization in both encrypted and free text form- and 
prior to the selective allowmg, verifying authenticity of the prindpa. identifier and firs, authorization 

encoding using a public key corresponding to the private key. 

2 1 . A method as in claim 20, further comprising: 

supplying the encrypted form of a, least the identifier for the pnncipa. and the firs, authonzahon ,o a 

chen, ent,ry external to the security architecture as a session token; 
the Cent entity presenting the sess.on token w.th subsequent access requests so ,ha, the security 

archuecture may perform me selecive allowing of the subsequent access requests w.thou, 

additional login credential authenticating. 

22. A method as in claim 21, 

wherein the client entity includes a browser; and 
wherein the session token is encoded as a cookie.. 
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23. A method as in claim 18, further comprising: 

on an access request for which the first authorization encoded by the cryptographically secured 
session credential is insufficient, 

obtaining a second login credential and authenticating the principal thereby: 
.ssuing a second cryptographically secured session credential encoding a second 

authorization accorded based on the authenticating by the second login credential; 

and 

selectively allowing the access request based on sufficiency of the second authorization 
encoded by the second cryp.ographically secured session credential. 

24. A method as in claim 18, 

wherein the cryptographically secured session credential also encodes an exp.ration; 
the method further comprising: 

prior to the expiration, reauthenticating the principal by the first login credential; 

issuing a third cryptographically secured sess.on credential encoding a third authorizat.on 

accorded based on the authenticating by the first login credential; and 
selectively allowing subsequent access requests based on suffic.ency of the third 

authorization encoded by the third cryptographically secured session credential. 

25. A method as in claim 24, 

wherein the first and third authorizations are equivalent. 

26. A method as in claim 24, 

wherein the first and third authorization are encoded as trust levels that differ in accordance with 

either or both of a changed session environment and changed mappings of credential types to 
trust levels. 



27. A method as in claim 18, 

wherein the login credent.al is selected from a set of credent.al types including one or more of a 

username password pair, digital certificate, an encrypted credentials based on asymmetric, 
symmetric, public, private, or secret key technology, a one-time password, a b.ometric 
credential based on retinal scan, voice print, or finger print, and a possession based 
credential embodied in a smart card, Enigma card or physical key. 

28. A method as in claim 18, embodied as one or more computer program products including 
functionally descriptive information for directing a processor to perform the .ogin credential obtaining and 
pnncpa. authenticating, the cryptographically secured session credential issuing, and the selectively allowing 
access based on sufficiency of the firs, authorization by the cryptographically secured sess.on credentia. the 
one or more computer program products encoded by or transmitted in a, least one computer readable medium 
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se.ec.ed from the se, of a disk, tape or other magnet,, optica., or electron, storage medium and a network 
wireline, wireless or other communications medium. 

29. An information access conrrol facility comprising. 

an application proxy for receiving an access request targeting one of the information resources 

extracttng a cryptograph.ca.lv secured session token from the access request, and selecrively 
proxying the access request; 

means response to the application proxy for eva.uating suffic.ency of an authorization encoded 
.he cryptographically secured sess.on token for access to the targeted information 



in 

resource. 



30. An access conrrol facility as in cla.m 29, further comprising: 

credential gathering means response to an insufficient zero or more login credent.a.s associated 
w.th the sess.on, the credent.a. gathering means obtaining a login credentia. of type 
sufficent, if authenticated, to ach.eve a trust .eve. requirement of the targeted information 



and 



authenncahon means for receiv.ng the obtained ,ogi„ credentia., authent.catmg a principa, thereby 
and .ssu.ng a session credential corresponding to the session token. 

3 1 . An access control facility as in claim 29, further comprising: 

means for uansfemng the sess.on token between the access control facility and the Cent entity. 

transmit ^ 7" ^ ^ " " C ' a,m ^ emb ° d ' ed " " ^ ^ * « 

transmuted „ a, .east one computer readable medium selected from the set of a disk, tape or other magnetic 

optica,, or electronic storage medium and a network, wtre.tne, wireless or other commutations medium ' 
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(57) Abstract: A security architecture has been developed in which a single sign-on is provided. Session credentials are used to 
mamtain continuity of a persistent session across multiple accesses to one or more information resources, and in some embodiments 
across credential level changes. Session credentials are secured, e.g.. as a cryplographically secured session token, such that they 
may be inspected by a w.de variety of entities or applications to verify an authenticated Oust level, yet may not be prepared or 
altered except by a tested authentication service. Some embodiments of the present invention associate trust level requirements with 
information resources. Authentication schemes (e.g.. those based on passwords, certificates, biometric techniques, smart cards etc ) 
are associated with trust levels, and in some embodiments, with environmental parameters. For example, in one configuration a'loein 
service (120) obtains login credentials for an entity (e.g.. 170) commensurate with the trust level requirement(s) or an information 
resource or information resources (e.g.. 19 1 . 192, 1 93) to be accessed and with environment parameter* that affect the sufficiency or a 
given credential type. Once login credential (e.g.. 410) have been obtained for an entity and have been authenticated to a given trust 
level, session credentials (e g., 420) are issued and access is granted to information resources for which the trust level is sufficient 
Advantageously, by using the session credentials access is granted without the need for further login credentials and authentication 
In some configurations, session credentials evidencing an insufficient trust level may be remedied by a session continuity preserving, 
upgrade of login credential. 6 
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